The present invention relates generally to a program architecture for a real time industrial control system and particularly to a program structure well suited for the development of complex, real-time operating systems for industrial controllers.
Industrial controllers are special purpose computers used for controlling industrial processes or manufacturing equipment. Under the direction of a stored program, the industrial controller examines a series of inputs reflecting the status of the controlled process and changes outputs effecting the control of the process. The inputs are most simply binary, that is "on" or "off", however analog inputs and outputs taking on a continuous range of values are also used. The binary inputs and outputs may be represented by single bits of data; the analog inputs and outputs may be represented by multiple-bit data words.
It is desirable in industrial control that the outputs change in response to the inputs in a way so that the operation of the control program is predictable, race conditions are minimized, and the relative order of control tasks is preserved. For these reasons, industrial controllers normally employ a three step execution sequence. In the first step, inputs to the industrial controller from sensors or other devices on the controlled process are collected and stored in an input/output (I/O) table so as to create a snapshot of the inputs at a given instant in time. In the second step, a user-defined control program is executed using the inputs from the I/O table as frozen in time. The execution of the control program creates outputs which are written to the I/O table. In the final step, outputs from the I/O table are transmitted to the particular machines as control outputs to actuators and the like and the process is repeated.
Traditionally, larger industrial controllers have used dedicated circuitry for the input and output scanning steps allowing the primary processor to be dedicated to the execution of a control program. With the advent of increasingly powerful microcontrollers, however, it is possible to perform all the steps of input scanning, output scanning and execution of the control program on a single general purpose processor to create a compact, versatile control unit. Such a "processor-based" system must additionally handle numerous other tasks including the monitoring of communication channels and error conditions and responding to higher level mode control commands from the user, all the while preserving real-time control.
Following normal procedures for software development, the operating system may be divided into a number of smaller "modules" each of which may be developed independently by a separate team of individuals. Each module may be separately tested and then integrated with the others. The high degree of interaction between the modules of an industrial controller operating system and the complex interaction between the modules and hardware of the industrial controller make testing and integration of the modules particularly challenging. Each module may need to be tested alone and in various combinations with other modules. For this purpose, it is known to write "stubs", that is dummy modules that handle calls from the modules being tested to the modules not being tested, so as to accommodate their interactions. Creating the stubs is burdensome and in many cases complicated. Poorly written stubs may introduce additional errors into the program.
In an industrial controller, it is normal for the operating system to operate in a number of modes in which different functions are activated or deactivated. For example, the industrial controller may be operated in a "program mode" where inputs are read but the control program is not executed so as to test the input lines and circuitry. A "test mode" allows the inputs to be read and the control program run, but no outputs are created, allowing testing of the control program. Finally, a "run mode" allows all three of: reading inputs, executing the control program, and writing outputs to occur. These mode changes are typically invoked by "front panel" switches (which may in fact be from a remote terminal) representing user inputs that override all other tasks of the operating system. Mode changes in the operating system may be implemented through mode flags read by "test" instructions placed in the various modules of the operating system. Embedding these "test" instructions throughout the operating system code is cumbersome and makes development and testing of the operating system difficult. A similar problem occurs when different versions of the controller are produced which have different functional requirements and thus which require different combinations of the modules.
What is needed is a program structure that allows for simplified development of modules of a real-time operating system for an industrial controller, the integration and testing of the modules, the selective activation of modules according to mode changes in the operating system or different configurations of the controller.